A video service is a multimedia service integrating information such as a voice, an image, and data together to perform long-distance transmission. A service provided by the video service is a video conference, which may include three types of content, an image, a voice, and data such that when persons at different places communicate with each other, a person can hear sound of another person, and can also see an image of the other person, thereby enhancing a sense of reality, a sense of intimacy, and a sense of immediacy of communication. The video service can be applied to such fields as military, politics, economy, education, and health, to make full use of its advantages of reality, high efficiency, and real-timeliness in order to provide people with simple, convenient and effective means of communication, management, collaborative decision-making, and the like.
A videoconferencing service is one of video services, and is a communication manner of holding a conference between two places or among multiple places by means of a video technology and device and using a transmission channel. In other approaches, a multipoint control unit (MCU) is a control core of a videoconferencing system. The terminals need to be controlled using the MCU when more than two terminals participate in a conference.
In some approaches, a point-to-point call or an MCU conference needs to be migrated to another MCU conference.
For example, a user A uses a terminal A, a user B uses a terminal B, and a user C uses a terminal C. The user A and the user B establish a point-to-point call between the terminal A and the terminal B. As shown in FIG. 1, when the user A and the user B are in conference, it is found that the user C also needs to participate in the conference. That is, the terminal A, the terminal B, and the terminal C need to join the same conference, that is, a two-point conference becomes a three-point conference. After the point-to-point call is established between the terminal A and the terminal B, the terminal A initiates a call to make the terminal C also join the conference, and then calls of the terminal A, the terminal B, and the terminal C are all transferred to an MCU multipoint conference. In this way, the terminal A, the terminal B, and the terminal C can have a conversation in the same conference.
Using a Session Initiation Protocol (SIP) call as an example, a procedure is shown in FIG. 2, and the procedure includes the following steps.
Step (1): Establishing a point-to-point call between the terminal A and the terminal B;
Step (2): Calling, by the terminal A, the terminal C after holding the call;
Step (3): Requesting, by the terminal A using a special merger uniform resource identifier (Merger URI) call, a SIP Server to schedule an MCU conference, and returning a corresponding conference URI to the terminal A;
Step (4): Instructing, by the terminal A using Refer, the terminal B to transfer the call to the conference URI;
Step (5): Calling, by the terminal A, the corresponding conference URI to join the MCU conference;
Step (6): Calling, by the terminal B, the corresponding conference URI to join the MCU conference;
Step (7): Releasing the call between the terminal A and the terminal B; and
Step (8): Similarly, instructing, by the terminal A, the terminal C to transfer the call to the conference URI, calling, by the terminal C, the corresponding conference URI to join the MCU conference, and releasing the call between the terminal A and the terminal C in order to implement that the terminal A, the terminal B, and the terminal C join the MCU conference together.
The technology of changing two points into three points provides a solution that to add a third point to a conference, two terminals in a point-to-point call migrate the conference to an MCU. However, the technology merely implements adding the terminals in the point-to-point call and a terminal of the third point to a same conference. For the terminal A and the terminal B, if an original conference is an encrypted conference, a newly-established conference may become an unencrypted conference. Consequently, experience in the point-to-point call cannot be kept consistent with experience in the MCU conference to which the original conference is migrated.
As processing capabilities of terminals are enhanced, some terminals have a Mini MCU function.
As shown in FIG. 3, a user A uses a terminal A having the Mini MCU function, a user B uses a terminal B, a user C uses a terminal C, and a user D uses a terminal D. The user A, the user B, and the user C need a remote video conversation. Therefore, a three-point conference is held on the terminal A having a Mini MCU. The terminal A, the terminal B, and the terminal C join the conference. In a discussion process, the user A, the user B, and the user C find that the user D also needs to participate in the conference. That is, the terminal A, the terminal B, the terminal C, and the terminal D need to join the same conference. However, a capability of the Mini MCU of the terminal A is limited, a resource is insufficient, and only three points can access the conference. In this case, the existing conference needs to be migrated to an MCU having a sufficient capability.
A conference is held on the terminal A having the Mini MCU function. The terminal A, the terminal B, and the terminal C join the Mini MCU conference. The terminal A initiates a call making the terminal D also join the conference, and then calls of the terminal A, the terminal B, the terminal C, and the terminal D are all transferred to an MCU multipoint conference. In this way, the terminal A, the terminal B, the terminal C, and the terminal D can have a discussion in the same conference. Specific steps are shown in FIG. 4.
Step (1): Holding, by the Mini MCU of the terminal A, a three-point conference, where the terminal A, the terminal B, and the terminal C join the conference.
Step (2): Calling, by the terminal A, the terminal D after holding the call.
Step (3): Requesting, by the terminal A using a special Merger URI call, a SIP Server to schedule an MCU conference, and returning a corresponding conference URI to the terminal A.
Step (4): Instructing, by the terminal A using Refer, the terminal B to transfer the call to the conference URI.
Step (5): Calling, by the terminal A, the corresponding conference URI to join the MCU conference.
Step (6): Calling, by the terminal B, the corresponding conference URI to join the MCU conference.
Step (7): Releasing the call between the terminal A and the terminal B.
Step (8): Similarly, instructing, by the terminal A, the terminal C and the terminal D to transfer the call to the conference URI, calling, by the terminal C and the terminal D, the corresponding conference URI to join the MCU conference, and releasing the call among the terminal A, the terminal C, and the terminal D.
In this way, the terminal A, the terminal B, the terminal C, and the terminal D join the MCU conference together.
In the foregoing procedure, an example in which the conference is held on the terminal having the Mini MCU function is used for description. Similarly, when an independent MCU cannot satisfy a requirement of a current conference because of an insufficient resource, similarly, a conference migration request may be initiated from a terminal side, to migrate the conference from the current MCU having an insufficient resource to another MCU having a sufficient resource.
The foregoing procedure provides a solution of migrating the conference on the Mini MCU to the MCU when the resource on the Mini MCU is insufficient. However, experience of a user participating in the conference after the migration cannot be kept consistent with that before the migration.